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Scope 



The present document provides the ETSI endorsement of the 3GPP TS 23.228 "IP Multimedia Subsystem; Stage 2, 
version 7.2.0". 

The present document provides the necessary adaptions to the 3GPP IP Multimedia Core Network Subsystem (IMS), in 
order to support the Access Networks and terminals in the scope of the present NGN Release. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

[I] 3GPP TS 23.228: "3rd Generation Partnership Project; Technical Specification Group Services 

and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 7)". 



Endorsement notice 

The elements of 3GPP TS 23.228 [1] apply, with the following modifications. 

NOTE: Underhning and/or strike-out are used to highlight detailed modifications where necessary. 

3 Global modifications to 3GPP TS 23.228 

3GPP TS 23.228 [1] was originally written specifically with mobile terminals in mind accessing the IMS using GPRS. 
Unless otherwise specified in the present document, requirements indicating mobile terminals should be taken as also 
being applicable to all terminals accessing the NGN. 

Additionally replace items in 3GPP TS 23.228 [I] as follows: 

• "HSS" with "UPSF". 

• "IM CN Subsystem" with "IMS Core". 

NOTE: Those changes are assumed globally for the present document. 

Clause 2 "References" 

Insert the following references at the end of clause 2: 

[45] IETF RFC 3022: "Traditional IP Network Address Translator (Traditional NAT)" . 

[46] ETSI ES 282 003: "TISPAN NGN; Resource and Admission Control Subsystem (RACS)". 

[47] ETSI TS 183 017: "TISPAN NGN; Gq' interface based on DIAMETER protocol". 
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[48] 



3GPP TR 23.981 (Release 6): "3rd Generation Partnership Project; Technical Specification Group 
Services and System Aspects; Interworking aspects and migration scenarios for IPv4 based IMS 
Implementations (Release 6)". 



4 Modifications to the main body of 3GPP TS 23.228 

Replace the references in 3GPP TS 23.228 [1] as shown in the table below. 





Reference in 3GPP TS 23.228 [1] 


Applicability to the present document 


1 


3GPP TS 23.002: "Network Architecture". 


ETSI ES 282 001 : "Telecommunications and Internet 
converged Services and Protocols for Advanced 
Networking (TISPAN); NGN Functional Architecture 
Release 1". (note 1) 


5 


GSM 03.64: "Digital cellular telecommunication system 
(Phase 2+); Overall Description of the General Packet Radio 
Service (GPRS) Radio Interface; Stage 2". 


(note 2) 


6 


GSM 01 .04: "Digital cellular telecommunications system 
(Phase 2+); Abbreviations and acronyms". 


(note 2) 


7 


3GPP TS 23.221 : "Architectural Requirements". 


(note 2) 


8 


3GPP TS 22.228: "Service requirements for the IP multimedia 
core network subsystem". 


ETSI TR 181 012: "Telecommunications and Internet 
Converged Services and Protocols for Advanced 
Networking (TISPAN); Services requirements and 
capabilities analysis for home networks connected to 
TISPAN NGN", (notel) 


9 


3GPP TS 23.207: "End-to-end QoS concept and 
architecture". 


(note 2) 


10 


3GPP TS 24.228: "Signalling flows for the IP multimedia call 
control based on SIP and SDP". 


(note 2) 


10a 


3GPP TS 24.229: "IP Multimedia Call Control based on SIP 
and SDP; Stage 3". 


ETSI ES 283 003: "Telecommunications and Internet 
converged Services and Protocols for Advanced 
Networking (TISPAN); Endorsement of "IP 
Multimedia Call Control Protocol based on Session 
Initiation Protocol (SIP) and Session Description 
Protocol (SDP) Stage 3 (Release 6)" for NGN 
Release 1". (note 1) 


11 


3GPP TS 25.301 : "Radio interface protocol architecture". 


(note 2) 


19 


3GPP TS 33.203: "Access Security for IP-based services". 


(note 2) 


21 


3GPP TS 26.235: "Packet Switched Multimedia Applications; 
Default Codecs". 


ETSI TR 181 012: "Telecommunications and Internet 
Converged Services and Protocols for Advanced 
Networking (TISPAN); Services requirements and 
capabilities analysis for home networks connected to 
TISPAN NGN", (notel) 


23 


3GPP TS 23.060: "General Packet Radio Service (GPRS); 
Service description; Stage 2". 


(note 2) 


24 


3GPP TS 23.003: "Technical Specification Group Core 
Network; Numbering, addressing and identification". 


(note 2) 


25 


3GPP TS 32.240: "Telecommunication management; 
Charging management; Charging architecture and principles". 


ETSI ES 282 010: "Telecommunications and Internet 
Converged Services and Protocols for Advanced 
Networking (TISPAN); Charging (Endorsement of 
3GPP TS 32.240 v6.3.0, 3GPP TS 32.260 v6.3.0, 
3GPP TS 32.297 v6.1 .0, 3GPP TS 32.298 v6.1 .0 and 
3GPP TS 32.299 v6.4.0 modified)", (note 1) 


26 


3GPP TS 32.260: "Telecommunication Management; 
Charging Management; IP Multimedia Subsystem (IMS) 
charging". 


ETSI ES 282 010: "Telecommunications and Internet 
Converged Services and Protocols for Advanced 
Networking (TISPAN); Charging (Endorsement of 
3GPP TS 32.240 v6.3.0, 3GPP TS 32.260 v6.3.0, 
3GPP TS 32.297 v6.1.0, 3GPP TS 32.298 v6.1.0 and 
3GPP TS 32.299 v6.4.0 modified)", (note 1) 


27 


3GPP TS 22.071 : "Technical Specification Group Services 
and System Aspects, Location Services (LCS); Service 
description, Stage 1". 


(note 2) 


28 


3GPP TS 23.271 : "Technical Specification Group Services 
and System Aspects, Functional stage 2 description of LCS". 


(note 2) 
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Reference in 3GPP TS 23.228 [1] 


Applicability to the present document 


29 


3GPP TS 23.078: "Customised Applications for IVIobile 
network Enhanced Logic (CAMEL) Phase 3 - Stage 2". 


(note 2) 


29a 


3GPP TS 22.340: "IMS Messaging; Stage 1". 


(note 2) 


30 


3GPP TS 29.228: "IP Multimedia (IM) Subsystem Cx and Dx 
Interfaces; Signalling flows and message contents". 


ETSI TS 183 033: "Telecommunications and Internet 
converged Services and Protocols for Advanced 
Networking (TISPAN); IP Multimedia: IP Multimedia 
Subsystem (IMS) Cx and Dx Interfaces; Signalling 
flows and message contents & IP Multimedia (IM) 
Subsystem Cx and Dx Interfaces; Cx and Dx 
interfaces based on the Diameter protocol [3GPP 
TS.29.228 v.6.8.0 and 3GPP TS.29.229 v.6.6.0, 
modified]", (note 1) 


31 


3GPP TS 23.240: "3GPP Generic User Profile - Architecture; 
Stage 2". 


(note 2) 


32 


3GPP TS 22.250: "IP Multimedia Subsystem (IMS) group 
management; Stage 1". 


(note 2) 


36 


3GPP TS 23.141 : "Technical Specification Group Services 
and System Aspects, Presence Service". 


ETSI TS 182 008: "Telecommunications and Internet 
converged Services and Protocols for Advanced 
Networking (TISPAN); Presence Service; Architecture 
and functional description (Endorsement of 3GPP 
TS 23.141 and OMA-AD-Presence SIMPLE-V1 0)". 
(note 1) 


37 


3GPP TS 26.141 :"IMS messaging and Presence; Media 
formats and codecs". 


(note 2) 


NOTE 1 : The reference in 3GPP TS 23.228 [1] is replaced by tlie document listed on the right column. This 
replacement is applicable to all occurrences of the reference throughout the present endorsement. 

NOTE 2: The reference in 3GPP TS 23.228 [1] contains 3GPP specific requirements and is not generally applicable to 
the present endorsement. 



3.1 Definitions 

Add the following definition: 

Network Address Translation (NA(P)T): method by which IP addresses are mapped from one group to another, 
transparently to end users. Network Address Port Translation, or NA(P)T is a method by which many network 
addresses and their TCP/UDP (Transmission Control Protocol/User Datagram Protocol) ports are translated into a 
single network address and its TCP/UDP ports. See RFC 3022 [45] for further details. 

Replace the definition of "ALG" as follows: 

Application Level Gateway (ALG): application specific functional entity that allows communication between 
disparate address realm or IP versions when certain applications carry network addresses in the payloads like SIP/SDP. 
NA(P)T-PT or NA(P)T is application unaware whereas ALGs are application specific translation entities that allow a 
host running an application to communicate transparently with another host running the same application but in a 
different IP version or IP address realm. 

For IMS, an IMS ALG provides the necessary application function for SIP/SDP protocols in order to communicate 
between different address realms or IP versions. 



3.2 Symbols 

Add the following symbols or notes to the symbols in 3GPP TS 23.228 [1] as shown below: 

(Not relevant in NGN Release 1) 



Ix 
Gq' 
Mx 
Mx 



Reference Point between IMS ALG and NA(P)T-PT 

Reference Point between an IBCF and the SPDF 

Reference Point between a CSCF and IMS ALG (Not relevant in NGN Release I) 

Reference Point between a CSCF/BGCF and IBCF 
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3.3 Abbreviations 

Modify the following abbreviations as shown below: 

HSS Home Subscriber Server (Not relevant in NGN Release 1) 

IN Intelligent Network 

NAPT Network Address Port Translation 

NAT Network Address Translation 

NASS Network Attachment Subsystem 

RACS Resource and Admission Control Subsystem 

SPDF Service Policy Decision Function 

UPSF User Profile Server Function 

4.0 General 
Modify as shown below: 

- replace "PLMN operators" with "PLMN and other operators" 

- figure 4.0 is not endorsed 

4.1 Relationslnip to CS domain and tine IP-Connectivity Access Network 

Modify the following sentence: 

The- Certain IP-CANs can maintains the service while the terminal moves and hides these moves from the IP 
multimedia subsystem. 

4.2.1.1 Support for CAMEL 

Modify the title and the text as follows: 

- replace "CAMEL" with "CAMEL or IN" 

- replace "CSE" with "CSE or IN Service Environment" 

4.4 Signalling concepts 
Modify the text as follows: 

A Single session control between the UE and CSCF: 

For Multi-Media type services delivered via the PS Domain within this architecture, a single session control 
protocol shall be used between the user equipment UE and the CSCF (over the Gm reference point). 

Protocols over the Gm reference point: 

The single protocol applied between the UE and CSCF (over the Gm reference point) within this architecture 
will be based on SIP (as defined by RFC 3261 [12], other relevant RFCs, and additional enhancements 
required to support 3GPP's needs). 

A Single session control on the Mw, Mm, Mg, Mi, Mj, Mk, Mx: 

A single session control protocol shall be used on the session control interfaces between: 

MGCF and CSCF (Mg), 

between CSCFs (Mw), 
between a CSCF/IMS ALG and external IP networks (Mm), 

between a CSCF and external IP networks (Mm), 

between an IBCF and external IP networks (Ic) 
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between IMS ALG and external IP networks (Mm). (Not relevant for Release 1 but may exist in 3GPP 
Release 6 networks) 

between CSCF and BGCF (Mi), 

between BGCF and MGCF (Mj), 

between BGCF /IMS ALG and BGCF (Mk), and 

NOTE: The above change should be fixed in 3GPP TS 23.228 and TS 23.002. 

between BGCF/CSCF and IBCF (Mx). 

Protocols for the Mw, Mm, Mg, Mi, Mj, Mk, Mx: 

The single session control protocol applied to these interfaces will be based on SIP (as defined by 
RFC 3261 [12], other relevant RFCs, and additional enhancements required to support 3GPP's needs). 

UNI vs. NNI session control: 

The SIP based signalling interactions between CN elements may be different than SIP based signalling between 
the UE and the CSCF. 

4.6.1 Proxy-CSCF 

Modify the text as follows: 

The Proxy-CSCF (P-CSCF) is the first contact point within the IM CN subsystem. Its address is discovered by UEs 
using the mechanism described in section "Procedures related to Local CSCF Discovery". The P-CSCF behaves like a 
Proxy (as defined in RFC 3261 [12] or subsequent versions), i.e. it accepts requests and services them internally or 
forwards them on. The P-CSCF shall not modify the Request URI in the SIP INVITE message. The P-CSCF may 
behave as a User Agent (as defined in the RFC 3261 [12] or subsequent versions), i.e. in abnormal conditions it may 
terminate and independently generate SIP transactions. 

NOTE: When requests are sent towards another domain they may, if required, be routed via a local network exit 
point (IBCF), which will then forward the request to the entry point of the other domain. More details on 
this can be found in Section 4.13 and Annex I. 

The Policy Decision Function (PDF) maybe a logical entity of the P-CSCF or a separate physical node. If the PDF is 
implemented in a separate physical node, the interface between the PDF and the P-CSCF is the Gq interface 
standardised in TS 23.207 [9]. 

The Service Policy Decision Function (SPDF) may be a logical entity of the P-CSCF or a separate physical node. If the 
SPDF is implemented in a separate physical node, the interface between the SPDF and the P-CSCF is the Gq' interface 
standardised in TS 183 017 [47]. 

The functions performed by the P-CSCF are: 

Forward the SIP register request received from the UE to an entry point determined using the home domain 
name, as provided by the UE. 

Forward SIP messages received from the UE to the SIP server (e.g. S-CSCF) whose name the P-CSCF has 
received as a result of the registration procedure. 

Forward the SIP request or response to the UE. 

Detect and handle an emergency session establishment request as per error handling procedures defined by 

stage-3. 

Generation of CDRs. 

If required for certain users, maintain a Security Association between itself and each UE, as defined in 
TS 33.203 [19]. 

Should p Perform s SIP message compression/decompression depending on the resources provided by the 
access technology in use and local policy . 
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Authorisation of bearer resources and QoS management. For details see TS 23.207 [9] and ES 282 003 [461 . 

Act as an ALG by changing the appropriate SIP/SDP parameters in order to translate addresses into same or 
different IP version addresses (see Annex G). 

4.14 Border Control concepts 

Modify as follows: 

Based on operator preference, border control functions may be applied between two IM CN subsystem networks or 
between an IM CN subsystem network and other SIP based multimedia network. These functions include: 

Controlling transport plane functions; 

Supporting functions to allow establishing communication between disparate address realms SIP applications; 

Providing network configuration hiding to restrict the following information from being passed outside of an 
operator's network: exact number of S-CSCFs, capabilities of S-CSCFs, or capacity of the network, etc; 

Screening SIP signalling information based on source/destination and operator policy (e.g. remove information 
that is of local significance to an operator); 

Generation of CDRs; 

Selecting the appropriate signalling interconnect; 

Insert an IWF in signalling route when required. 

In case border control concepts are to be applied in an IMS network, the IBCF acts as an entry point for this network 
(instead of the I-CSCF), and also acts as an exit point for this network. 

NOTE: In this case the IBCF and I-CSCF may be co-located as a single physical node. 

More detailed description of these functions is provided in Annex I. 

Interconnection occurs either between two Home IMS domains (e.g. originating to terminating domain) or between a 
Visited IMS domain and a Home IMS domain. The figures below provide an overall view of the use of IBCFs in the 
signalling path. 

The doted line boxes are optional in the architecture. 




Figure 4.13.1 : Interconnect scenarios 



£75/ 



11 



ETSI TS 182 006 V1.1.1 (2006-03) 



The following figures illustrates the use of IBCFs through an example end-to-end signalling path for a session were the 
originating and terminating users are roaming and with different home network operators performing origination and 
termination. 




Direction of the session 




Figure 4.13.2: Example of originating side SIP session path using IBCF entities 




Direction of the session 




Figure 4.13.3: Example of originating home to terminating home SIP session path 

using IBCF entities 




Direction of the session 




Figure 4.13.4: Example of terminating home to terminating visited SIP session path 

using IBCF entities 

Add the following clause: 

4.14.1 Interaction with tine RAGS 

The IBCF may interact with the RACS in order to do the following: 

Provide the RACS with information on the "resource reservation service class" required for a particular 
session; the "resource reservation service class" enables the RACS to derive transport layer characteristics 
required for a session (e.g. decision to include an I-BGF for the session, or media interconnect link 
selection...). 
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Request bindings data between the different IP addresses (NA(P)T or NA(P)T-PT) upon session 
initiation/modification. 

Release the bindings at session release. 

Open/close gates between domains (i.e. packets filtering depending on "IP address / port"). 

Perform packet markings 

Resource allocation and bandwidth reservation for upstream and downstream traffic. 

Policing of incoming traffic. 

The above functions may or may not instantiated by the IBCF depending on local policy and incoming signalling 
information. Additionally, the IBCF may decide, in some cases, based on the SIP signalling and operator-specific 
policy, not to contact the RACS. 

5.0 General 

Modify the text as follows: 

This section documents the main procedures that are used for the provision of services in the IP multimedia subsystem. 
These procedures are described using text description as well as information flow diagrams. The procedures described 
in this document are meant to provide a high level description and are not intended to be exhaustive. Additional 
procedures and details are provided in TS 21.228 [10] . 

In the following sections, user roaming /nomadism procedures apply to cases where P-CSCF is located in the visited 
network. Procedures for cases where the user is roaming visiting an access network outside the home network boundary 
and the P-CSCF is located in the home network are similar to procedures for a non-roaming /non-nomadic user. 

5.2.2.5 Stored information 

Modify the text as follows: 

Table 5.1 provides an indication of some of the information stored in the indicated nodes during and after the 
registration process. Note that Table 5.1 is not an exhaustive list of stored information, i.e. there can be additional 
information stored due to registration. 
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Table 5.1 : Information Storage before, during and after the registration process 



Node 


Before Registration 


During Registration 


After Registration 


UE - in local network 


Credentials 
Home Domain 
Proxy Name/Address 


Same as before 
registration 


Credentials 
Home Domain 
Proxy Name/Address 


Proxy-CSCF 

- in Home or Visited 

network 


Routing Function 


Initial Network Entry point 

UE Address 

Public and Private User 

IDs 

And if the P-CSCF is 


Final Network Entry point 

UE Address 

Public and Private User 

IDs 

And if the P-CSCF is 


located in a visited 


located in a visited 


network: 


network: 


- IBCF in the visited 


- IBCF in the visited 


network address/name 


network address/name 


Interrogating-CSCF - in 
Home network 


HSS or SLF Address 


Serving-CSCF 
address/name 
P-CSCF Network ID 
Home Network contact 
Information 


No State Information 


HSS 


User Service Profile 


P-CSCF Network ID 


Serving-CSCF 
address/name\ 


Serving-CSCF (Home) 


No state information 


HSS Address/name 
User profile (limited - as 
per network scenario) 
Proxy address/name 
P-CSCF Network ID 
Public/Private User ID 
UE IP Address 


IVIay have session state 
Information 
Same as during 
registration 



5.4 



Procedures for IP Multi-media sessions 



5.4.2a IP version interworking concepts 

Modify the text as follows: 

Following interworking scenarios exist: 

Application Level Interworking 

It should be possible for users connected to an IMS network to communicate with users that are connected to SIP based 
networks that use a different IP version via interworking or that are in a separate addressing range (e.g., NA(P)T 
functionality is set at the border of the IMS) . Annex I Section 5.18 describes in more detail how such interworking is 
performed for IMS. 

Transport Level Interworking 

Inter- working also includes tunnelling level interconnection of IMS networks via transit networks that use a different IP 
version using for example, configured tunnels as described in[7]. Figure 5.5b below shows an example configuration 
scenario where two IPv6 IMS networks are connected via an IPv4 network. 
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Figure 5.5b: Example tunnelling of IPv6 traffic over IPv4 networks 



5.4.4 



Requirements for IP multi-media session control 



Modify the text as follows: 

In order for operators to be able to offer a "carrier-grade" IP multimedia service, and to require bearers whose features 
(e.g. Bandwidth) are coherent with the media components negotiated through CSCFs, the following features shall be 
offered: 

1 . Both end points of the session shall be able to negotiate (according to service /UE settings,) which resources 
(i.e. which media components) need to be established before the destination party is alerted. The session 
signalling shall ensure that these resources (including IP-Connectivity Access Network resources and IP 
multimedia backbone resources) are made available or reserved before the destination UE rings. 

This should nevertheless not prevent the UE from offering to the end-user the choice of accepting or rejecting 
the components of the session before establishing the bearers. 

2. Depending on regulatory requirements, the IP multimedia service shall be able to charge the originating party 
for the IP-Connectivity Access Network service of both originating and destination side or when reverse 
charging applies to charge the terminating party for the IP -Connectivity Access Network service of both 
originating and terminating side. This implies that it should be easy to correlate CDR held by the IP- 
Connectivity Access Network service with a session. 

3. The session control function of IP multimedia network of an operator (CSCF) shall be able (according to 
operator choice) to have a strict control (e.g. on source /destination IP address, QoS) on the flows associated 
with session established through SIP entering the IP multimedia bearer network from IP-Connectivity Access 
Network service. This does not mean that CSCF is the enforcement point (which actually is the Gateway 
between the IP-Connectivity Access Network and the IP multimedia network) but that the CSCF may be the 
final decision point for this control. 

4. The session control and bearer control mechanisms shall allow the session control to decide when user plane 
traffic between end-points of a SIP session may start/shall stop. This allows this traffic to start/stop in 
synchronisation with the start/stop of charging for a session. 

5. The IP -Connectivity Access Network service shall be able to notify the IP multimedia session control when 
the IP-Connectivity Access Network service has either modified or suspendVed or released the bearer(s) of a 
user associated with a session (because e.g. the user is no longer reachable). 

6. The solution shall comply with the architectural rules relating to separation of bearer level, session control 
level, and service level expressed in 23.221 [7] . 
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5.4.5 Session Path Information 

Modify the text as follows: 

5.4.5.1 Session Patin Information during Registration and Session Initiation 

During registration and session initiation there are SIP mechanisms, which provide the means to determine the session 
path. 

After registration the P-CSCF stores the S-CSCF name , possibly IBCF names and the S-CSCF stores the P-CSCF name 
and possibly IBCF names (see 4.3.4) as part of the UE related information. 

There is a need to store the session path that is determined during the session initiation request in order to route the 
subsequent session requests through this determined path. This is needed in order to route these session requests 
through certain nodes, e.g. the ones performing Service Control , or interconnect functions . CSCFs are assumed to 
perform certain actions: 

1 . CSCFs (Proxy and Serving) store a certain part of the session path determined during session initiation. This 
allows CSCFs to generate requests that traverse all elements on a Route path. 

2. The P-CSCF shall check correct usage of the header values. Should an UE build inaccurate header(s) in a SIP 
request, the P-CSCF may reject the request. If an operator policy requires enforcing the routes stored in P- 
CSCF, the P-CSCF shall overwrite the header(s) provided by the UE with the appropriate values. 

5.4.7 Interaction between QoS and session signalling 

Clauses 5.4.7.0 to 5.4.7.7 are applicable to 3GPP IP-CANs only. 

Add the following clause: 

5.4.7a Interaction between RAGS and IMS 

The P-CSCF interacts with the RACS in order to do the following: 

Request bindings data between the different IP addresses (NA(P)T or NA(P)T-PT) upon session 
initiation/modification. 

Request media latching in hosted NAT scenarios. 

Release the bindings at session release. 

Open/close gates between domains (i.e. packets filtering depending on "IP address / port"). 

Perform packet marking. 

Resource allocation and bandwidth reservation for upstream and downstream traffic. 

Policing of incoming traffic. 

More details can be found in ES 282 003 [46] and TS 183 017 [47]. 

5.6 Origination procedures 

Modify the text as follows: 

5.6.1 (M0#1) Mobile origination, roaming 

This clause is endorsed with the clarification that "P-CSCF(PDF)" is replaced with "P-CSCF". 

5.6.2 (M0#2) Mobile origination, home 

This clause is endorsed with the clarification that "P-CSCF(PDF)" is replaced with "P-CSCF". 
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Insert the following clause: 

5.6.2a (F0#1) Fixed origination, Inome 

This origination procedure applies to users located in their home service area. As in clause 5.6.2, the UE is located in 
the home network, but is using an xDSL IP-CAN to access the IMS Core. 

NOTE: The below flows are example flows. The detailed stage 2 description of the RACS information flows can 
be found in ES 282 003 [46]. 
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Figure 5.15a: Fixed xDSL originating - home (example flow) 
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Procedure F0#1 is as follows: 



1 . UE sends the SIP INVITE request, containing an initial SDP, to the P-CSCF address determined with P-CSCF 
discovery mechanism. The initial SDP may represent one or more media for a multi-media session. 

2-6. A connection is reserved in the C-BGF with optional NAT binding list retrieval. 

7. P-CSCF remembers (from the registration procedure) the next hop CSCF for this UE. In this case it forwards 
the INVITE to the S-CSCF in the home network. 

8. S-CSCF validates the service profile, and invokes any origination service logic required for this user. This 
includes authorisation of the requested SDP based on the user's subscription for multi-media services. 

9. S-CSCF forwards the request, as specified by the S-S procedures. 

10. The media stream capabilities of the destination are returned along the signalling path, per the S-S procedures. 

11-15. S-CSCF forwards the Offer Response message to the P-CSCF which triggers the SPDF. The SPDF requests 
the A-RACF to perform admission control based on the Offer and Answer parameters. 

16-20 The SPDF configures the connections in the C-BGF based on the SDP answer and optionally requests a NAT 
binding list. 

21. UE decides the offered set of media streams for this session, confirms receipt of the Offer Response and sends 
the Response Confirmation to P-CSCF. The Response Confirmation may also contain SDP. This may be the 
same SDP as in the Offer Response received in Step 20 or a subset. If new media are defined by this SDP, a 
new connection configuration shall be performed following Step 2-6. The originating UE is free to continue to 
offer new media in this request or in subsequent requests using the Update method. Each offer/answer 
exchange will cause the P-CSCF to repeat the RACS interactions again. 

22. P-CSCF forwards this message to S-CSCF 

23. S-CSCF forwards this message to the terminating endpoint, as per the S-S procedure. 

24. The terminating end point responds to the originating end with an acknowledgement. If Optional SDP is 
contained in the Response Confirmation, the Confirmation Acknowledge will also contain an SDP response. If 
the SDP has changed, the admission control and configure connection flows are repeated. 

25-26. S-CSCF and P-CSCF forward the answered media towards the UE. 

27-29. The destination UE may optionally perform alerting. If so, it signals this to the originating party by a 

provisional response indicating Ringing. This message is sent to S-CSCF per the S-S procedure. It is sent from 
there toward the originating end along the signalling path. UE indicates to the originating user that the 
destination is ringing. 

30-3 1 . When the destination party answers, the terminating endpoint sends a SIP 200-OK final response along the 
signalling path to the originating endpoint, as specified by the termination procedures and the S-S procedures. 

32-39. P-CSCF performs the approval of QoS Commit procedure which triggers the Open Gates procedures if 
required. 

40. P-CSCF passes the 200-OK response back to UE 

41. UE starts the media flow(s) for this session. 

41-44. UE responds to the 200 OK with an ACK message which is sent to P-CSCF and passed along the signalling 
path to the terminating endpoint. 

Insert the following clause: 

5.7.2b (FT#1) Fixed termination, Inome 

NOTE: The below flows are example flows. The detailed stage 2 description of the RACS information flows can 
be found in ES 282 003 [46]. 
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This termination procedure applies to users located in their home service area. As in clause 5.7.2, the UE is located in 
the home network, but has registered to the IMS Core via an xDSL IP-CAN. 
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Figure 5.18b: Fixed xDSL terminating - home (example flow) 
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Procedure FT#1 is as follows: 



1. UE#1 sends the SIP INVITE request, containing an initial SDP, via one of the origination procedures and the 
S-S procedures, to the Serving-CSCF for the terminating UE. 

2. S-CSCF validates the service profile, and invokes any termination service logic required. This includes 
authorisation of the requested SDP based on the user's subscription for multi-media services. 

3. S-CSCF remembers (from the registration procedure) the P-CSCF address for this UE. The S-CSCF forwards 
the INVITE to the P-CSCF, which in this case is located in the home network. 

4-8. The P-CSCF triggers the SPDF which reserves a connection in C-BGF with optional NAT binding retrieval. 

9. P-CSCF remembers (from the registration procedure) the UE address, and forwards the INVITE to the UE. 

10. UE determines the subset of the media flows proposed by the originating endpoint that it is capable and willing 
to support, and responds with an Offer Response message back to the originator. The SDP may represent one 
or more media for a multi-media session. This response is sent to the P-CSCF. 

11-18. P-CSCF triggers the SPDF. The SPDF requests the A-RACF to perform admission control based on Offer 
and Answer parameters. 

15-18. SPDF configures the connection in the C-BGF based on SDP answer with optional NAT binding retrieval. 

19. P-CSCF forwards the Offer Response message to S-CSCF. 

20. S-CSCF forwards the Offer Response message to the originator, per the S-S procedure. 

21-26. The originating endpoint sends a Response Confirmation via the S-S procedure, to the terminating S-CSCF. 
The Response Confirmation may also contain SDP. This may be the same SDP as in the Offer Response sent 
in Step 19 or a subset. If new media are defined by this SDP, a new interaction with the RACS (as in Step 4-8) 
will be done by the P-CSCF. The originating UE is free to continue to offer new media in this request or in a 
subsequent request using the Update method. Each offer/answer exchange will cause the P-CSCF to repeat the 
RACS interactions (Step 4-8) again. 

27-29. UE may alert the user and wait for an indication from the user before completing the session. If so, it 

indicates this to the originating party by a provisional response indicating Ringing. This message is sent to 
P-CSCF and along the signalling path to the originating endpoint. 

30. When the destination party answers, UE sends a SIP 200-OK final response to P-CSCF. 

31-36. P-CSCF indicates that the resources reserved for this session should now be committed. 

37-38. P-CSCF forwards the 200-OK to S-CSCF, following the signalling path. 

39-41. The session originator responds to the 200-OK by sending the ACK message to S-CSCF via the S-S 
procedure and it is forwarded to the terminating end along the signalling path. 

Annex G (Normative): Reference Architecture and procedures winen tine NAT is invoked between tine UE and 
tine IMS domain 

Modify as follows: 

G.2 Reference model 

The requirements in this clause do not apply when RACS is used. 
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Add the following clause: 



G.2A 



Reference model with RACS 



Figure G.la presents the general reference model for IMS access when both the signalling and media traverses NAT 
devices. Figure G.2a presents the general reference model when IP address translation is needed between the IP-CAN 
and the IMS domain. The IMS network architecture is the same for both cases. 

NOTE: The P-CSCF and the C-BGF may belong to different operators. 
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Figure G.la: Reference model for IMS access where UE is located behind a hosted NAT 
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Figure G.2a: Reference model for IMS access with IP address conversion in the media path 

G.3 Network elements 

The requirements in this clause do not apply when RACS is used. 
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Add the following clause: 

G.3.1 A Required functions of tine P-CSCF witin RAGS 

For performing communication with UEs when IP address translation is needed between the IP-CAN and the IMS 
domain on the media path only (Figure G.2a) or on both the media and signalling (Figure G.la), the P-CSCF shall 
perform the following functions: 

Act as an IMS-ALG by changing the appropriate SIP/SDP parameters in order to translate addresses into same 
or different IP version addresses, in case NA(P)T or NA(P)T-(PT) is required between the IP-CAN domain 
and the IM Subsystem core network elements. 

Request the RACS to provide the IP address bindings data upon session initiation, to modify those bindings 
any time during the session, and to release the bindings at session release. 

Additionally in support of the hosted NAT scenarios (see Figure G.l), the P-CSCF shall request the RACS to initiate 
media latching, in order to retrieve the remote address information of the media received from, and sent to, a NAT 
device between the P-CSCF and the served UE. 

G.3.2 Required functions of the IMS Access Gateway 

The requirements in this clause do not apply when RACS is used. 

G.3.3 Iq reference point 

The requirements in this clause do not apply when RACS is used. 

G.4.3 Session establislnment procedure 

The requirements in this clause do not apply when RACS is used. 

G.4.4 Session release procedure 

The requirements in this clause do not apply when RACS is used. 

G.4.5 Session modification 

The requirements in this clause do not apply when RACS is used. 

G.4.6 Media forwarding in the IMS Access Gateway 

The requirements in this clause do not apply when RACS is used. 

Annex I (normative): Border Control Functions 

Modify as follows: 

Replace clause 1.2 by the following: 

1.2 Overall architecture 

Figure 1.2.1 presents a high-level architecture diagram showing how Border Control Functions fit into the IMS 
architecture. 
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Figure 1.1 : Border Control Functions 

The Mx reference point allows S-CSCF/I-CSCF/P-CSCF to communicate with an IBCF in order to provide border 
control functions. 

1.3.1 .1 Originating Session Flows towards IPv4 SIP network 

This clause is endorsed with the clarification that the TrGW is replaced by the I-BGF when the RACS is used. 

1.3.1 .2 Terminating Session Flows from IPv4 SIP network 

This clause is endorsed with the clarification that the TrGW is replaced by the I-BGF when the RACS is used. 
Add the following clause: 



I.3.2A 



Additional IBCF screening functions 



The IBCF can filter all SIP signalling information based on source/destination and operator policy (e.g. remove 
information that is of local significance to an operator). 



Add the following clause: 



I.3.2B 



Addition of the IWF 



The IBCF can detect whether an IWF needs to be added in the SIP signalling path. The IBCF can insert the IWF in the 
signalling route when appropriate. 
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Add the following annex: 



Annex ZA (normative): 
IP version considerations 



The present document does not place any requirement with regards to the IP version to be supported by UEs for 
accessing the IMS Core. More specifically the following scenarios are supported: 

IP version 4 only UEs accessing the IMS Core. 

IP version 6 only UEs accessing the IMS Core. 

Dual stack UEs accessing the IMS Core. 

The IP version used by IMS Core entities (e.g. CSCFs) to exchange SIP signalling depends on the IP version used by 
the terminals that a given operator is willing to support. A number of scenarios are hence possible. 

NOTE: An analysis of the requirements deriving for each of those scenarios in a GPRS environment can be found 
in 3GPPTR 23.981 [48]. 
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